A large fraction of the costs in a software system's life cycle is spent on its maintenance. Estimates of 85 to 90% were reported. One important reason why software maintenance tends to be costly is that long-living software systems such as legacy software systems can only be understood in part, and an up-to-date documentation describing the system's structure and behavior is rarely available. Hence, developers, including any person participating in software development and maintenance that operates on source code, devote up to 50% of their time to trying to understand the system's implementation. Likewise, more recent studies emphasize the importance of program understanding during maintenance (Basili, Evolving and packaging reading technologies, Journal of Systems and Software 38 (1997), No. 1, pp. 3-12; Ko et al., Information Needs in Collocated Software Development Teams, Proceedings of the 29th International Conference on Software Engineering, IEEE Computer Society, 2007, pp. 344-353).
One of the many reasons why program understanding is time consuming is that the system's internal behavior can only be inspected in parts. Developers need to re-establish the links between the external, visible behavior and the system's implementation. Known developer tools support developers by “showing” the inner processes either by providing information on the system's state at a single point in time (e.g., symbolic debuggers) or by providing time aggregated overviews (e.g., profilers). While these tools help developers to acquire an understanding of the system's execution, reconstructing the execution history needs to be done mentally—a cognitively demanding task.
The visualization of execution traces, i.e., sequences of function calls, represents an approach to help developers to understand a complex system's structure and behavior (Cornelissen et al., Understanding Execution Traces Using Massive Sequence and Circular Bundle Views, Proc. 15th IEEE International Conference on Program Comprehension ICPC '07, 2007, pp. 49-58; Be Pauw et al., Execution Patterns in Object-Oriented Visualization, Proceedings of the Conference on Object-Oriented Technologies and Systems, USENIX, 1998, 219-234; Renieris et al., Almost: Exploring Program Traces, Workshop on New Paradigms in Information Visualization and Manipulation, 1999, pp. 70-77). Trace visualization reveals the participating functions, their relationships, and their call order while the system runs and exhibits a specific externally visible behavior. In practice, execution trace visualization captures the sequence of function calls over time, analyzes and abstracts that data, and derives visual representations that permit developers to analyze the system's structure and behavior. Throughout the present application, the term trace is used synonymously with the term execution trace.
There are a number of commercial and academic program comprehension tools available that have been adopted by developers for daily use in an industrial software maintenance setting. However, these do not focus on trace visualization. The main reason for this is that building trace visualization tools encounters major scalability issues: First, it is computationally difficult to process the large amount of data that is typically produced when logging system behavior. Second, it is difficult to explore the vast amount of runtime data—a cognitive scalability issue. For example, capturing the behavior of the Google Chrome web browser for five seconds while it is downloading and displaying a web page involves more than 10 million function calls.
For man maintenance tasks, analysis tools and systems already exist. They allow developers to identify specific artifacts of the software system (e.g., functions, classes, files) that are relevant to the given maintenance task. Typically, the resulting artifacts contain false positives, i.e., artifacts not relevant to the task at hand. Identifying the true positives tends to be time consuming, especially if one needs to “dig into code” to distinguish between false and true positives. Applying trace visualization in these situations has the following benefits:                Trace visualization can often be applied as an intermediate step after having received the set of artifacts and before analyzing the code manually to verify that an artifact is relevant to the given maintenance task. Trace visualization facilitates comprehension of the execution context of the artifacts and helps to eliminate false positives.        Combining trace visualization with other analysis tools and systems helps to master the scalability issue. The resulting artifacts provide developers with precise entry points for trace exploration. They may perform detailed trace analysis without having to search for maintenance task relevant parts in the trace via a top-down exploration.        
Applying information visualization techniques in the domain of software engineering is referred to as software visualization. Software sometimes is inherently intangible and invisible. The goal of software visualization is to provide computer images which evoke mental images for comprehending software better.
Software visualization may be regarded as a useful and powerful technique for helping programmers understand large and complex programs. Likewise, the need for software visualization has been emphasized when having to cope with challenging development processes: A basic necessity in this context are methods and tools to improve program understanding. An accepted and powerful technique to manage the various stages of the software lifecycle—especially during specification, design, programming, and program analysis—is visualization.
A broad definition of software visualization may be given as follows: Software visualization refers to the use of various visual means in addition to text in software development. The various forms of development means include graphics, sound, color, gesture, animation, etc. Software development life cycle involves the activities of project management, requirement analysis and specification, architectural and system design, algorithm design, coding, testing, quality assurance, maintenance, and, if necessary, performance tuning.
Price et al. (A Principled Taxonomy of Software Visualization, Journal of Visual languages and Computing 4 (1993), No. 3, pp. 211-266) define the term software visualization as follows: Software visualization is the use of the crafts of typography, graphic design, animation, and cinematography with modern human-computer interaction and computer graphics technology to facilitate both human understanding and effective use of computer software.
Also, the following definition may be proposed: Software visualization is a representation of computer programs, associated documentation and data, that enhances, simplifies and clarifies the mental representation the software engineer has of the operation of a computer system. A mental representation corresponds to any artifact produced by the software engineer that organizes his or her concept of the operation of a computer system.
A more restrictive definition of software visualization may be given: Software visualization is the visualization of artifacts related to software and its development process. In addition to program code, these artifacts include requirements and design documentation, changes to the source code, and bug reports, for example. Researchers in software visualization are concerned with visualizing the structure, behavior, and evolution of software.